The so-called "Transport stream" and "Program Stream" as defined within the MPEG-2 standard provide a standardized mechanism for the transmission and storage of MPEG compressed audio and video (A/V) information. Both streams contain time stamps to synchronize the decoding and presentation of the conveyed audio and video information while ensuring that data buffers in the decoders do not overflow or underflow during linear playback. In addition, these time stamps are used for the correct delivery of the streams themselves. The MPEG Transport Stream is tailored to the communication or the storage of one or more programs of digital data in environments in which significant errors may occur. Such environments are for example terrestrial and satellite broadcast channels, cable channels, and other telecommunication networks. The MPEG Program Stream is tailored to communication or storage of one program of digital data in environments where errors are very unlikely, and where software processing of system coding is a major consideration. Such environments are, for example, PCs with optical and magnetic storage media.
In the last few years, significant effort has been devoted to applications that involve the linear playback and transmission of Program and Transport Streams. For example, broadcasting MPEG-2 encoded programs involves the distribution of Transport Streams of infinite length. However, the non-linear playback of MPEG Transport Streams and Program Streams from video servers has not received the same level of attention. Nonlinear playback involves the interruption and continuation of the stream and is necessary for basically all kinds of trick modes. Trick-modes require an accurate control of the stream. For local disc-based systems, solutions are known to support trick-modes such as pause, slow motion, and fast forward. However, the known solutions can not be applied to network environments, because networks differ from local systems in two aspects.
The first aspect is the delay decoder-network-server-network-decoder. This delay, which is further referred to as the network latency, is not constant and can have a magnitude of up to one second. A consequence of the network latency is that after the end-user requests a pause (resulting in a stall of the decoding and display process and sending a pause command to the server), the network will continue to deliver bits to the decoder for some period of time. The subsequent continuation of the stream is also complicated by the network latency. Namely, because of the network latency there is a significant delay between the transmission of the `Resume` command to the server and the arrival of the requested bits at the decoder. The bits delivered after the pause command and the temporary lack of bits after the resume command have to be handled by the decoder in such a way that the decoder can flawlessly resume its decoding and display process.
The second aspect is the possible presence of MPEG-2 remultiplexers in the network. The presence of remultiplexers complicates the support for trick-mode because remultiplexers allow the packets having different PIDs in a Transport Stream to be reordered. A PID is a Packet IDentifier as defined in the MPEG-2 standard. In practice this means that the packets do not enter the decoder in the same order as they were sent by the server. Note that the presence of remultiplexers does not complicate the trick-mode support for Transport Streams with only one PID, e.g. video, because remultiplexers are not allowed to reorder the packets within one PID.